Migrating from sysvinit
~~~~~~~~~~~~~~~~~~~~~~~
SysV inittab format, also partially supported by busybox init:

	name:runlevels:action:command

sninit inittab format uses whitespaces for field separators,
and merges runlevels and action into mode field:

	name   runflags   command



Actions
~~~~~~~
respawn		S for "slow" entries like foreground daemons
		F for entries like gettys that can and do actually respawn

once		R with the same runlevels
wait		W with the same runlevels

sysninit	W, no runlevels, and place before any other entries
boot		R, place before other entries but after sysinit
bootwait	W, place before other entries but after sysinit

ondemand	S or F with the same secondary runlevel
		(that is, ":a:ondemand: becomes "Sa")
	beware of multiple runlevels: for sysvinit, :ab:ondemand:
	means either a or b, while in sninit it's a *and* b.

off		(not implemented)

initdefault	not supported, specify desired runlevel in kernel command line.
		sninit behaves as if initdefault is always 3

powerwait	not supported; use either a primary or a secondary runlevel
powerfail	 to track power states, and telinit to switch them.
powerokwait
powerfailnow

ctrlaltdel	not supported / not needed
		Upon receiving SIGINT, sninit will start switching
		to runlevel 0, rebooting the system once it's there.

kbrequest	not supported, sninit ignores SIGWINCH


Runlevels
~~~~~~~~~
In sninit, r-type entries ("wait" and "once") are only
started in-between runlevels, i.e. when moving from runlevel N to runlevel M.
Services, or s-type entries ("respawn") are started during the switch, but may
be restarted later when init has already settled in runlevel M.

Mixing primary (0123456789) and secondary (aka ondemand, abcdef) runlevels
is allowed; "23a" means "run on / when entering runlevels primary runlevels
2 or 3, but only if secondary runlevel a is activated".

While in sysvinit runlevels 0 and 6 were special mostly by convention,
in sninit reaching runlevel 0 prompts a reboot(2) call and runlevel 6 should
not be special in most sane configurations. Both halt, reboot and poweroff use
runlevel 0, the only difference being the argument passed to reboot in the end.

Runlevels 789 are allowed in sninit, but designated "slippery" unless configured
otherwise. That is, upon reaching any of these runlevels, init will immediately
start a switch back to the last non-slippery runlevel it was in.
This is to allow sleep/suspend to be implemented as runlevels,
see slippery.txt.


Commands
~~~~~~~~
If you want a command to be spawned via sh -c "command", request it
explicitly: "!command". Unlike sysvinit, sninit does not spawn processes
via shell just because there are unusual characters in the command.

For interactive processes, run -Y. Conventional "-command" is not supported.


Reboot and friends
~~~~~~~~~~~~~~~~~~
In sninit, reboot, poweroff and halt are all runlevel 0, which is assumed
to mean "stop everything".  Also, there are no reboot, poweroff and halt
commands; use telinit reboot, telinit poweroff and telinit halt instead.


Signals
~~~~~~~
sninit does not reload configuration on SIGHUP, use telinit q instead.
This is mostly because of error reporting, telinit q will show errors while
SIGHUP will leave them in syslog.

In sninit, SIGHUP works just like SIGUSR1 in sysvinit, forcing init to reopen
its control socket. Should be useless as long as said socket is @initctl, but
for /dev/initctl, it may be necessary.

sninit ignores SIGWINCH. No replacement as this point, it is just ignored.

sninit handles SIGINT somewhat differently due to different approach
to rebooting.  Still, the end result should be exactly the same, Ctrl-Alt-Del,
if allowed to reach init, will cause the system to reboot.
